Technical Field
Disclosed embodiments relate to systems and methods of authentication and/or authorization, and more specifically, to such systems and methods using geo-location tools in mobile devices.
Description of the Related Art
The security community has long sought a viable second factor to supplement and fortify passwords as a means for user authentication. Previous attempts have been hamstrung by solutions that are too expensive and cumbersome to enjoy mainstream adoption.
Much to the chagrin of the security community, passwords have stubbornly remained the only authentication mechanism in place for the vast majority of user accounts. This is likely due to the simplicity and ease of use that passwords provide account holders. When used as the sole factor for authentication, however, passwords present a litany of issues: they are often either hard to remember or easy to guess, users tend to reuse their passwords with many accounts, they are often stored insecurely both at the client and the server, etc. The consensus has long been that there is a compelling need for an additional mechanisms to supplement and fortify this irksome first factor. A multitude of solutions have been proposed over the years, all promising to provide this much needed additional factor—but for various reasons none have found widespread adoption beyond a relatively small niche user-base. The larger world of mainstream users remains unprotected and would greatly benefit from a solution that does not extensively affect existing authentication routines.
Recently, some multi-factor authentication (MFA) mechanisms have been used; however, none of these known solutions are ideal. Many MFA mechanisms in current use center around the use of a security token. In this scheme, users are issued a token, often a small hardware device with a screen which displays a seemingly random number that changes periodically. Users that have paired a token with a network resource must supply the number currently on the screen at any given moment as part of the login procedure (in addition to a static password, the first authentication factor). If the provided code matches an expected value at a token-aware backend for a given instance, then the system grants the authentication request—feeling confident that a request that can provide a password (something known) and a valid code from the token screen (something possessed) is reasonably likely to be an authentic request. Security schemes using hardware tokens have been relatively successful as a multi-factor authentication mechanism; however these schemes have been limited almost exclusively to environments where use is mandated (e.g., required for login to a corporate VPN, etc.). The lack of widespread adoption outside these mandatory use environments may be attributable to two primary barriers to entry: the significant infrastructure required to implement such systems (e.g., complicated backend servers, hardware costs, etc.) and the inconvenience to a user in having to retrieve a token and transcribe a code every time a login is required.
More recent solutions have mitigated some of the daunting infrastructure requirements, such as the MFA mechanisms deployed by companies such as Facebook and Google. These kind of mechanisms provide software-based tokens that reside on the mobile devices that many of their users already carry on their person. However, these systems still require the user to retrieve his/her mobile device, launch the required application, and transcribe the code currently displayed on the mobile device screen. Many users find this solution to be cumbersome and irritating.
Some other recent solutions use location awareness of a mobile device as a part of a larger authentication process; however, these approaches require the transmission of a user's location or other identifying information to a central server. This raises privacy concerns for users where large amounts of personal data (e.g., daily travel habits) are stored on a third party server where the data may not be secure.
Other location-based approaches require a priori or on-demand location awareness for terminal devices attempting the authentication.
Thus, there is a need for a system that achieves multi-factor authentication without significantly burdening the user while, at the same, time eliminating the need for complicated infrastructure implementations.
This specification includes references to “one embodiment” or “an embodiment.” The appearances of the phrases “in one embodiment” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
Various units, circuits, or other components may be described or claimed as “configured to” perform a task or tasks. In such contexts, “configured to” is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs the task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the “configured to” language include hardware—for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that unit/circuit/component.